VPN
'IPSec VPN' (Site to Site VPN) *A single VPN tunnel may be sufficient for connection between a single central site and a remote site. *Connections between a central site and multiple remote sites require VPN tunnels for each central - remote site pair. *Each tunnel is bound to a tunnel interface (clear text) traffic. **When a packet comes to the firewall, the route lookup funtion can determine the appropriate tunnel to use. The tunnel interface appears to the system as a normal interface, and the existing routing infrastructure can be applied. *'Each tunnel interface can have a MAX of 10 IPSec tunnels'. **allows you to set up IPSec tunnels for individual networks that are all associated with the same tunnel interface on the firewall. 'IKE '(Internet Key Exchange) *'IKE Gateways' = specify the configuration information necessary to perform IKE protocol negotiation with peer gateways. The other device should always be the initiator for the VPN tunnel, the other device should not be in passive mode (responder mode). 'IKE CRYPTO PROFILES:' 1.' IKE Phase 1 (IKE Crypto)' *''authenticates the firewalls to each other and sets up a secure control channel.'' *It uses IKE-Crypto profile for IKE SA negotiation. OPTIONS for IKE SA: *Diffie-Hellman (DH) Group = DH groups to use when generating public keys for IKE. *Encryption = Encryption algorithms *Hash Algorithm *Lifetime = Specify the length of time that the negotiated key will stay effective. 2. IKE Phase 2 (IPSec Crypto) *''Negotiates IPSec SA parameters and sets up matching IPSec SAs in the peers.'' *It uses IPSec Crypto profile for IPSec SA negotiation. OPTIONS for IPSec SA: *(ESP) Encapsulating Security Payload = select options for authentication, data integrity, confidentiality, and encryption. *(AH) Authentication Header = Select options for authentication and data integrity. (not generally used) *Perfect Forward Security (PFS) Diffie-Hellman (DH) group = DH groups to use in generating independent keys for IPSec *Lifetime = specify the length of time that the negotiated key will stay effective. 'Configuration' ''1. Configure tunnel endpoint to the PAN device: Network -> Interfaces -> Tunnel tab *'Name': (EX: tunnel.1) *'Virtual Router': (select the existing VR) *'Zone': (select the layer 3 internal zone from which the traffic will originate) 2. Configure IKE Phase 1 Gateway: (IKE Crypto) 'Network -> Network Profiles -> IKE Gateways -> New *'IKE Gateway:' (give it a name) *'Interface: Selected the ethernet *'''Local IP address: (select the firewall interface that is closest to the other VPN endpoint, AKA the Public interface) *'Peer IP address': (enter the IP address of the Public interface on the other VPN endpoint) *'Pre-Shared Key': (enter the key. Make sure it's the exact same on the other firewalls VPN's configuration) '''''3. Configure the IKE phase 2 IPSec Tunnel: (IPSec Crypto) Network -> IPSec Tunnels Create a new VPN: *Name: (any name you choose ex: VPN-to-siteX) *Tunnel interface: (select tunnel.1 in the drop down) *Type: select either to use an automatically generated or manually entered security key. **Auto key - must have IKE Gateway and IPSec Crypto Profile *IKE Gateway: (in drop down select the IKE Gateway from step 2) *IF the other side of the tunnel is configured as a policy-based VPN or NON-PAN device, then select "SHOW ADVANCED OPTIONS" **Enter the local proxy ID '''and '''remote proxy ID to match the other side. (see below for more info) Once you hit OK the IPSec tunnel will appear in the list, with the status circles colored red indicating the tunnel is down. ''4. Add Static Routes to the Virtual Router: Network -> Virtual Router *Add a new route for the network that is behind the other VPN endpoint. *Interface: (the tunnel from step 1. EX: Tunnel.1) *Can leave next hop blank. *Hit "add" to add the static route *'Commit''' ''5. Configure the tunnel endpoint on the PAN device: Configure the other end of the tunnel for a route based VPN. By default, the Palo Alto devices use: 3des/aes128 with sha1, PFS with DH group 2. IF you want to change the PAN settings then edit the following to meet your standards: *'PHASE 1': Network -> Network Profiles -> IKE Crypto -> Default *'PHASE 2': Network -> Network Profiles -> IPSec Crypto -> Default 6. TESTING THE VPN: *Ping from the device on the far network, through the VPN, and to a target PC on the local network protected by the PAN firewall. **The first ping will fail, but the rest should be successful. *Check the '''Monitor -> Log -> System' **'filter it by''' port.dst eq 500''' *'Network -> IPSec Tunnel:' should now show Green status **First status light is Phase 2; second status light is Phase 1. 'Testing using CLI:' *Verify the tunnel state: **''>''' show vpn flow *To confirm the data is going over the tunnel: **> show vpn flow tunnel-id'' ''' ***you will see a count of encrypted and decrypted packets and bytes in the tunnel. This value should change as you send more data over the tunnel. *To view details on the active IKE phase 1 SAs: **> show vpn ike-sa gateway '' *To view details on active IKE phase 2 SAs: **> 'show vpn ipsec-sa tunnel ''' 'PROXY-ID' (PAN to Cisco ASA, Checkpoint, Juniper SRX, Junier Netscreen) Network -> IPSec Tunnels -> add -> Proxy ID (tab) For the PANFW to establish a tunnel with firewalls that are using or have to use a Policy Based VPN, you must configure the PANFW VPN tunnel with proxy ids, which are mirror images to the policies for the VPN traffic written on the other firewalls. Mandatory to configure the proxy-ids, whenever you establish a tunnel between the PAN and the firewalls configured for the Policy Based VPNs. 'Policy Based VPNs:' *The IPSec tunnel is invoked during policy lookup for traffic matching the interesting traffic. *There are no tunnel interfaces. The remote end of the interesting traffic has a route pointed out through the default gateway. *As there are no tunnel interfaces, we cannot have routing over VPNs. *The policies/access-lists configured for the interesting traffic serve as the proxy-ids for the tunnels. Policy Based VPNs have specific security rules/policies or access-lists (source addresses, destination addresses and ports) configured for permitting the interesting traffic through the IPSec tunnels. These rules are referenced during the quick mode/IPSec phase 2, and are exchanged in the 1st or 2nd messages as the proxy-ids. If the PANFW is NOT configured with the proxy-id settings, the ikemgr daemon sets the proxy-id with the default values of source ip: 0.0.0.0/0, destination ip: 0.0.0.0/0 and application:any, and these are exchanged with the peer during the 1st for the 2nd message of the quick mode. A successful phase 2 negotiation requires not only that the security proposals match, but also the proxy-ids on either peer, be a mirror image of each other. 'Route Based VPNs: '(PANFW, Juniper SRX, Juniper Netscreen, Checkpoint) *The IPSEC tunnel is invoked during route lookup for the remote end of the proxy-ids. *The remote end of the interesting traffic has a route pointing out through the tunnel interface. *Supports routing over VPNs. *Proxy IDs are configured as part of the VPN setup. 'Troubleshooting IPSec VPNs' (PAN to Other Vendor) 'Test network connectivity:' *Confirm the network is up betweenthe two firewalls: **On Firewall-A, ping its public interface to public interface of Firewall-B. ***> ping source x.x.x.x host y.y.y.y'' **Then to the opposite and ping Firewall-B to Firewall-A. ***>'' ping source y.y.y.y host x.x.x.x'' *Confirm LAN connectivity between the firewalls and the local PC: **On Firewall-A, ping from internal interface to PC-A ***> 'ping source host ''' **On Firewall-B, ping from internal interface to PC-B 'Initiate IKE Phase 1:' Attempt to bring up IKE phase 1. Initiate the tunnel from either side. To initiate IKE Phase 1 from network-OTHER: *ping from PC-OTHER and PC-PAN. *Then examine the system log on the PAN firewall To initiate IKE Phase 1 from network-PAN: (then check the error messages on the OTHER firewall) *ping from PC-PAN to PC-OTHER *Or, on the PAN run command: **> test vpn ike-sa gateway '' **> show vpn ike-sa gateway ''' ***'''''if the output shows an SA, that means that IKE Phase 1 is up. ***If it does NOT show an SA, look at the system logs of the target firewall: ****> show log system subtype equal vpn direction equal backward'' '''Initiate IKE Phase 2: *Ping from PC-OTHER to PC-PAN or the other way around *''test vpn ipsec-sa tunnel '' *''show vpn ipsec-sa tunnel '' **'If the output does NOT show an SA, Phase 2 didn't complete successfully. Look at the event logs IF there is a STALE or DISCARD session showing in the system logs. clear the session id. *> show session all filter source '' **OR'' > show session all filter application ike'' *> show session id <#####>' *> clear session id <#####>'' Continuous traffic will be sent through the tunnel and the session timer will never expire. This will cause the IKE phase 1 or 2 to keep failing. ---- 'TUNNEL IS UP, STILL CANNOT PING END TO END:' *Check the routing table on the PAN firewall. Are the proper routes there? **''test routing fib-lookup virtual-router ip '' *Check the policies on the PAN. Is the traffic arriving in a zone different than the zone that contains the tunnel interface? **if YES, you must create a policy to allow that traffic to traverse zones. *Check the routing table and policies on the other Firewall. Use traceroute on the other firewall to se the route packets are taking. ---- If still having issues with connectivity: *Check the context, make sure it is not maxed out on the unit **> show running tunnel flow info ***if 'encap/decap context total' or 'tunnel nexthop' is the same as 'Used'. Then the context is MAXed out and the unit is too small for the configurations. ****PA-200 = 74 max ****PA-500 = 525 max 'COMMANDS:' 1. To monitor the tunnel or verify that the tunnel is active: *''> show vpn flow'' 2. To confirm that data is passing through the tunnel: *''> show vpn flow tunnel-id X'' (where X is.. get the ID number from the show vpn flow command) > tail follow yes mp-log ikemgr.log ---- 1. To tear down the VPN Tunnel: *''> clear vpn ike-sa gateway ''' *> clear vpn ipsec-sa tunnel ''' 2. Bring the tunnel back up: *''> test vpn ike-sa gateway '' *''> test vpn ipsec-sa tunnel '' 'TECH DOCUMENTS:' 'troubleshooting VPN connectivity issues:' *https://live.paloaltonetworks.com/docs/DOC-3671 'IPSec VPN timeout issue between CISCO ASA router and PANFW:' *https://live.paloaltonetworks.com/docs/DOC-1675 *https://live.paloaltonetworks.com/thread/10421